1. Field of the Invention
The present invention generally relates to a debug supporting method capable of preparing program execution environments with high reliability. More specifically, the present invention is directed to a method of acquiring a heap dump, which is advantageously used so as to detect/specify a memory leak.
2. Description of the Related Art
Normally, program execution environments are provided with memory managing mechanisms (heap memories) which dynamically allocate memory regions in response to requests issued from programs under execution. The programs store objects in the allocated memory regions so as to process these stored objects, and then, return the allocated memory regions at the time when necessities of holding the objects are lost (namely, release of objects).
An action in which a certain object has an ID of another object as data is called as “to refer”, which is generally used as a programming method. In order to release an object, the below-mentioned two process operations are carried out. That is, in one process operation (1), referring to this object is canceled; and in another process operation (2), the memory region thereof is released. Depending upon program execution environment, a program may merely execute the process operation (1), whereas the other process operation (2) is automatically executed by the program execution environment. In general, this function is referred to as a “garbage collection.”
Such a phenomenon is called as a “memory leak”, where an object which is not required in order to execute a process operation of a program is not released to be left. When a memory leak happens to occur, a memory region which can be utilized by the program is decreased. Thus, there are some cases that the performance of this program is lowered and the process operation by the program cannot be executed. An occurrence of such a memory leak is caused by mis-programming. In order to solve a memory leak problem, the following object statuses must be specified, namely which object is not released to be left, and an object is not released because how the object refers.
Generally speaking, in order to specify such an object which constitutes an occurrence cause of a memory leak, the following sequential investigation is carried out: (1) It is to specify that a memory leak occurs when what operation is carried out (memory leak reproducing sequence). (2) A heap dump is acquired before and after the specified memory leak reproducing sequence is performed. (3) A difference is calculated between the two acquired heap dumps. As a result, since the memory leak reproducing sequence is carried out, such objects are specified which are newly produced and are not released to be left. These remaining objects may strongly constitute the occurrence cause of the memory leak.
After the objects which constitute the occurrence cause of the memory leak have been specified, a reference relationship among the objects is investigated based upon the acquired heap dumps, and thus, the reason why these objects are not released is specified.
The technical idea related to the above-explained object specifying operation is described in JP-A-11-312097.